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Abstract — Industrial robotics is characterized by sophisti- 
cated mechanical components and highly-developed real-time 
control algorithms. However, the efficient use of robotic systems 
is very much limited by existing proprietary programming 
methods. In the research project SoftRobot, a software architec- 
ture was developed that enables the programming of complex 
real-time critical robot tasks with an object-oriented general 
purpose language. On top of this architecture, a graphical 
language was developed to ease the specification of complex 
robot commands, which can then be used as part of robot 
application workflows. This paper gives an overview about 
the design and implementation of this graphical language and 
illustrates its usefulness with some examples. 

I. Introduction 

When programming robots to perform long-lasting and 
complex tasks, the programmer usually wants to abstract 
from the technical details of controlling the robot hardware, 
e.g. hard real-time constraints, closed-loop controllers, or 
controller parameters. The focus should rather lie on the 
what aspect of the task [1]. In the research project SoftRobot, 
an extensible software architecture [2] has been developed 
to both facilitate the development of robotic applications 
with the aforementioned level of abstraction, and at the 
same time keep real-time constraints in mind. This multi- 
layer architecture (cf. Fig. [T} allows to program industrial 
robots using a standard, high-level programming language 
(e.g. Java) and, at the same time, ensures that commands are 
executed on the robot hardware with real-time guarantees. 

The SoftRobot architecture provides application program- 
mers with the Java-based Robotics API [3], an object- 
oriented, extensible application programming interface for 
robot applications. The Robotics API contains an open 
domain model of (industrial) robotics describing the available 
actuators and devices, as well as possible actions and tasks, 
and also includes ways of maintaining a world model of the 
relevant parts of the environment. The Robotics API allows 
to specify actions to be executed by actuators (for example, a 
linear movement by a robot), and to combine multiple actions 
in different ways to create more complex commands. Every 
such command is guaranteed to be executed with certain real- 
time guarantees considering the timing of all actions and 
their combination. As an example, consider the case of a 
line welding application in the automotive industry: robots 
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Fig. 1. Robot application are programmed against the Robotics API. 
High-level commands specified using the Robotics API are automatically 
transformed into dataflow graphs at runtime and executed with real-time 
guarantees. 



equipped with welding tools perform welding operations 
following series of continuous, complex geometric shapes. 
The workpieces in this case are (quite expensive) car bodies, 
which requires sophisticated handling of process errors in 
order to not damage the bodies. If an error occurs during 
a welding operation, the welding tool has to be turned off 
immediately (meaning with a maximum delay of at most 
some milliseconds) and probably even needs to be moved 
away quickly from the surface. Such operations have to be 
executed with hard real-time guarantees, while application 
developers still want to be able to specify them on a high 
level of abstraction and in an application- specific way. 

To meet those real-time requirements, the Robotics API 
relies on the Robot Control Core (RCC) layer. At run- 
time, Robotics API commands are transformed to a data- 
flow language called Realtime Primitives Interface (RPI) [4] 
which is implemented by the RCC. The dataflow language 
consists of (robotics-specific) calculation blocks which are 
referred to as (real-time) primitives and are connected by 
data-flow links to form a graph, referred to as primitive 
net. During execution of a primitive net, each primitive is 
evaluated cyclically. The primitives have known worst-case 
execution time and thus allow the execution of the task 
in a deterministic manner. As the RCC is responsible for 
real-time execution of primitive nets and for controlling the 
robotic hardware, it must be running on a real-time operating 
system. A reference implementation of an RPI-compatible 
RCC [4] was developed using OROCOS [5] and Linux with 
Xenomai real-time extensions. 



Robotics API commands and their combination can be 
specified using mechanisms of the object-oriented Java lan- 
guage, such as instantiation of command objects and compo- 
sition of commands by calling respective API methods. This 
mechanism proved to be very flexible and able to express 
a large variety of complex tasks that are common in the 
industrial robotics domain. However, practical experience 
has also shown that the definition of complex command 
structures often results in long and confusing program code. 
To overcome this, several approaches have been considered 
and evaluated. Some efforts have been made to introduce a 
simpler API while at the same time still providing enough 
flexibility and extensibility. Another idea that was investi- 
gated and constitutes the main contribution of this work is 
the development of a graphical formalism for specifying such 
command structures, as they seemed quite well suited for 
being expressed graphically. The resulting graphical specifi- 
cation tool proved to be a real step forward and enables much 
quicker specification of Robotics API command structures. 
Code generated from such a specification can be easily used 
inside Robotics API programs. In this paper, we present the 
design and implementation of this graphical language and 
illustrate its usefulness with examples. 

Before presenting the main contribution, the next section 
will give an overview about existing work in the area of 
graphical programming languages for robots. The following 
Section (TTTJ describes the characteristics of the Robotics API 
and its command model. Sect. [TV] describes the design 
principles of the proposed grapical language, whereas Sect.lVl 
presents details of its realization. Sect. |VI]presents a practical 
example of a robot task specified with the developed lan- 
guage. Finally, Sect. IVIII gives a conclusion and an outlook. 

II. Related Work 

Roboticists have developed various tools for graphical 
specification of robot actions. Some frameworks relying 
purely on dataflow-based specification of robot actions like 
ControlShell or ORCCAD provide graphical editors for their 
dataflow diagrams [6] [7]. In [8], graphs of data processing 
operators based on the Dual Dynamics architecture can be 
specified graphically in order to synthesize robot controllers. 

While the aforementioned approaches are roughly re- 
lated to the RPI layer in the SoftRobot architecture, other 
approaches operate on higher abstraction levels. Mission- 
Lab supports graphically specifying configurations of inter- 
related robot behaviors [9] . Manufacturers of industrial robot 
systems like KUKA and ABB are also investigating the 
possibilities of graphical languages for robotics and are 
proposing approaches [10] [11]. 

Other frameworks used in the robotics research commu- 
nity today also incorporate graphical tools. The Robotics 
Developer Studio (RDS) from Microsoft includes the Visual 
Programming Language (VPL) [12] that can orchestrate 
services created with the RDS. The research robot NAO by 
Aldebaran Robotics comes bundled with the development 
tool Choreographe that also includes means for graphically 
orchestrating robot behaviors [13]. State Machines are also 



often used for implementing robot behavior. The ROS0 
framework includes at least a visualization tool for State 
Machines implemented using the tool SMACtfl. 

The Command model used in the RoboticsAPI was de- 
signed to introduce a level of abstraction that is useful for 
programming complex tasks of industrial robotic systems 
(for details see [14]). At the same time, those Commands 
are designed to be transformable to real-time primitives nets 
that the Robot Control Core can execute, guaranteeing hard 
timing constraints. These different kinds of constraints led 
to some special characteristics of the designed Command 
model that neither make it a data-flow language, nor directly 
comparable to existing paradigms like Software Services 
or Abstract State Machines. Thus, reusing parts of existing 
graphical languages seemed to be infeasible. For this reason 
we propose a new Domain Specific Language tailored to 
the RoboticsAPI Command Model. The next sections will 
describe the structure of the RoboticsAPI more in detail 
and after that present the proposed graphical language for 
specifying RoboticsAPI Commands. 

III. Structure of the RoboticsAPI core 
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Fig. 2. Class structure of the RoboticsAPI core 

The RoboticsAPI is intended to serve as an extensible 
object-oriented framework for creating robotic applications. 
Due to its framework nature, its core parts define a general 
class structure that may be extended for use with concrete 
hardware and creating specific applications. In this section, 
we give an overview of this core structure. Fig. [2] depicts the 
most basic concepts and their relationships. In the following, 
we will explain all parts step by step. 

Hardware devices that can be controlled in any way are 
modeled as Actuators (cf. Fig. O bottom left). An example of 
a more specialized Actuator would be a robot arm. Actuators 
have some properties (e.g. the number of joints) and can 
be configured in certain ways (e.g. defining the maximum 
allowed velocity of motions). Actuators in the RoboticsAPI 

1 http://www.ros.org 
2 http://www.ros.org/wiki/smach 



in general do not contain code that implements the execution 
of any kind of action (e.g. the interpolation of motions). They 
can rather be seen as proxy objects representing devices in 
the Robot Control Core (cf. Fig. [TJ. 

Actions that Actuators should execute are modelled by the 
class Action. An example would be a linear motion of a robot 
arm in space. Like Actuators, Actions carry parameters (e.g. 
the velocity of a linear motion). To let an Actuator execute an 
Action, a Runtime Command has to be defined. It combines 
exactly one Actuator with exactly one Action. Like all other 
Commands, RuntimeCommands provide methods to actually 
execute them. When one of those methods is called, the 
specification of the Command is transformed into a primitive 
net, which is then sent to the RCC and executed there in 
a real-time environment. Details on this transformation and 
execution process can be found in [15]. 

To create more complex task specifications (e.g. a robot 
motion during which a tool action should be executed), 
the other types of Commands can be used. A Transac- 
tionCommand is a composition of other Commands. All 
contained Commands (and their scheduling rules, see below) 
are executed in the same real-time context. This means that, 
upon execution, they are transformed into different parts 
of the same primitive net and executed atomically by the 
RCC. To define scheduling rules, EventHandlers can be used. 
EventHandlers are attached to Commands and can influence 
their execution by executing EventEffects. An example would 
be stopping a Command when certain events occur. When 
attaching an EventHandler to a TransactionCommand, it is 
e.g. also possible to let the EventHandler start one of the 
child Commands contained in the TransactionCommand. 

EventHandlers can be triggered upon changes in the state 
of the system. The concept State models a certain part of 
this system state. A State can be active at any point in 
time, or not active. An EventHandler can be triggered when 
the activeness changes, i.e. when the State is becoming 
active or inactive. States can be provided by Commands as 
well as Actuators, Actions and Sensors. Commands provide 
States expressing e.g. that the Command has been started 
or stopped. Actuators provide mostly error States (e.g., a 
robot's drives are disabled), while Actions can provide States 
like e.g. a Motion having been executed to a certain degree. 
Sensors are providing data that is measured in some way. 
Boolean-type sensors (like a digital field bus input measuring 
a high or low value) provide a State that directly corresponds 
to the measured value. For more complex sensor data, the 
RoboticsAPI allows defining derived Sensors that process 
this data in order to provide States (e.g. the condition that 
'a laser scanner sees an object in a distance smaller than a 
value X' can be expressed as a State). 

All the concepts presented above can be used to create 
arbitrarily complex structures of Commands. Due to the 
fact that each such structure is guaranteed to be executed 
with hard real-time timing guarantees, a large variety of 
applications can be realized. The RoboticsAPI was already 
used to e.g. perform robot motions with collision detection, 
for force-based part assembly with defined maximum force 



// Robot icsRuntime is the Factory for Commands 
RoboticsRuntime rt = Robot icsRegistry . getSingle ( 
"orocos", Robot icsRuntime . class) ; 

// create motion RuntimeCommand for LWR 

LWR lwr = RoboticsRegistry . getSingle ( "lwr" , LWR. class); 

PTP ptp = new PTP ( 

lwr . getHomePosition ( ) , // start 

new doublet] {1.57, 0, 0, 1.57, 0, 0, 0} // goal 
) ; 

RuntimeCommand ptpCmd = rt . createRunt imeCommand ( lwr , ptp); 

// create command for setting field bus output 
DigitalOutput o = RoboticsRegistry . getSingle ( 

"gripperClose" , DigitalOutput . class) ; 
SetDigitalValue close = new SetDigitalValue (true) ; 
RuntimeCommand closeCmd = rt . createRunt imeCommand (o, set); 

// combine both commands 

TransactionCommand trans = rt . createTransact ionCommand ( ) ; 
trans . addStartCommand (ptpCmd) ; // auto-start Command 
trans . addCommand ( closeCmd) ; // no auto-start 

trans . addStateEnteredHandler ( 

ptp.getMotionTimePercent (30) , // State 

new CommandStarter (closeRt ) ) ; // EventEffect 

// execute TransactionCommand 
trans . execute ( ) ; 



Listing 1. Robotics API Command Example 



or for cooperative transport of workpieces by multiple robot 
arms, requiring tight synchronization of the arms. 

To illustrate the composition of Robotics API commands, 
Listing [T] gives a Java code example. Here, a robot is 
instructed to execute a simple Point-To-Point (PTP) motion 
in joint space, while at a certain progress of the motion, its 
gripper is opened by setting a field bus output. This simple 
example shows that the code required to define a hierarchy 
of Commands and rules for scheduling their execution tends 
to get long and complex. Worse than the pure code size is the 
fact that it is hard to read the "big picture" (i.e. the resulting 
Command) from this kind of definition, as the hierarchical 
structure of Commands is hard to capture from this kind 
of textual definition. As stated previously, different ways to 
tackle this problem have been examined, with the approach 
presented in this paper being one of them. 

IV. Design of the Graphical Language 

In this section, we present the design of the GSRAPID 
language. GSRAPID stands for Graphical SoftRobot 
RoboticsAPI Diagram and refers to the graphical models 
that can be defined. In the following, all important concepts 
of this language are explained. 

A. Basic Operators 

The graphical language designed to specify complex 
RoboticsAPI Commands contains a set of basic graphical 
operators. Those operators represent mainly the concepts 
presented in the previous section. Furthermore, some opera- 
tors allow to define relationships between other operators to 
resemble relationships between Commands. 

There are two ways of defining a relationship between 
entities: nesting and connecting. If an object A (e.g. a State) 



[rt] Default Item 



A nestable item like this can either represent any type of 
Command, an Actuator, an Action, or a Sensor, depending 
on the icon in the upper left corner. It supplys one compart- 
ment for the inner nestable objects and one compartment 
for inner States. 



Regular State item, which belongs to a Command. The label 
identifies the type of State. 



cj ActiveState 



LogicalState, which is composed of other States by ingoing 
And State connec tions. The rectangular shape suggests the compos- 
able character of this item, while the round corners identify 
it as a State. 



Represents an entry-point for a Diagram from where the 
contained Commands can be started. 



Connection between a State and a Command. The labels 
express the event handler parametrization described in 
section IIV-DI 




StateEntered 
Starter 



Connection either between a State and a LogicalState, or 
between a starter and a Command. There is no labeling 
needed, since the context of usage clearly defines its 
function. 



TABLE I 
Basic graphical operators 



can be added to Diagrams as needed. TransactionCom- 
mands inside Diagrams are graphically modeled as special 
nestable items. They can themselves contain nestable items, 
in this case further Commands (TransactionCommands or 
RuntimeCommands) . 

RuntimeCommands are also modeled as nestable items. 
In contrast to TransactionCommands, they can only contain 
exactly one Action and one Actuator as inner items. As 
described in [TTT1 this specifies that the Action has to be 
executed by the Actuator. An example is shown in Fig. [3] The 
element labeled (1) is a RuntimeCommand with an Actuator 
(4) and an Action (5) nested inside. 



RT ptpRuntimeCommand 




$ StateFirstEntered Starter 



[ff| openRuntimeCommand 



f* openOutput@LbrLeft 

® 



^SetDigitalValue 



Fig. 3. A Diagram defined in the graphical language 



is nested inside another object B (e.g. a Command), then 
object A is graphically surrounded by object B. This rela- 
tionship doesn't always fully specify the interaction between 
the nested objects and the surrounding ones, but defines 
a cohesiveness that can carry semantics. The scheduling 
of different Commands is achieved by connecting different 
graphical objects which results in a graph, resembling a 
complex Robotics API Command. 

The basic graphical operators are defined in Table U 
In addition to the pure graphical definition, each operator 
may have a set of properties attached. The values of those 
properties can be specified separately from the language 
diagram in a dedicated property editor. By this separation 
of graphical representation and property values, the visual 
clarity of the language is preserved. 

B. Diagrams and Commands 

Graphical RoboticsAPI Commands are specified inside a 
so called Diagram. A Diagram is considered the top-level of 
a graphical Command specification. During code creation, 
it is translated to a Robotics API TransactionCommand. 
To make a diagram a valid Command specification, the 
following rules need to be followed: 

• At least one Command (cf. Fig. [3] item marked 1) has 
to be present within the created Diagram. 

• There has to be at least one entry-point for the command 
(cf. Fig. El 2) 

In order to start a command from one of the entry points, 
so called "StarterConnections" (cf. Fig. [5] 3) have to point to 
the commands that shall be started first. Further Commands 



C. Sensors and States 

The prerequisite for defining execution-time scheduling 
dependencies between RoboticsAPI Commands are States 
(see Sec. (TTT1> . As explained before, States can be provided 
by Commands, Actuators, Actions or Sensors. To reflect this 
in the graphical language, States can be nested inside the 
graphical operators that resemble those concepts. 

Sensors themselves can be embedded in a Diagram in two 
ways: They can either be nested in an Actuator (cf. Fig. [3] 
6), or, depending on the type of Sensor, be defined as a 
toplevel sensor in the Diagram. As States can be defined 
based on Sensor data (e.g. the State that a force sensor 
measures a value greater than 5N), graphical State items 
can be nested inside Sensor items (cf. Fig. 7). States, 
however, are not limited to Sensors and can also be added 
to the graphical representations of Actions, Actuators and 
Commands. Fig.[3]shows a CommandState (8) which belongs 
to the RuntimeCommand and represents the state that this 
command has been completed. 

In addition to the regular States, LogicalStates have a 
special graphical representation (cf. Fig. [3] 9). They are 
States that are derived from one or more other State(s). This 
deriviation is symbolized by the StateConnections in Fig. 
[3j 10. Like the other States, LogicalStates are connected to 
the commands they shall have an effect on by EventEffect- 
connections (cf. Fig. [3] 11). 

D. Command scheduling 

The event mechanism is the core concept for scheduling 
Commands in the graphical language. An EventHandler can 



be specified graphically by inserting an EventEffect con- 
nection originating from a State and targeting a Command. 
Further details concerning the scheduling are specified as 
properties of this connection and visualized as labels of the 
connection. These details include constraints specifying on 
which kind of event to react (State (first) entered/State (first) 
left) as well as the effect of the event. Possible effects are 
e.g. starting, stopping and cancelling the targeted Command. 

With this kept in mind, the schedule in Fig. [3] could 
be expressed as: "If the TorqueReachedSensor state has 
appeared for the first time on the Actuator LbrLeft or the 
RuntimeCommand ptpRT is in a completed state for the first 
time, start the RuntimeCommand open" 

V. Realization 

To enable users to create RoboticsAPI Commands with 
GSRAPID, a graphical tool called GSRAPID IDE was cre- 
ated. The Eclipse IDE was chosen as the basis for this tool 
mainly for two reasons: On the one hand, there exists a 
variety of stable Eclipse-based frameworks for creating cus- 
tom (graphical) languages (cf. Sec. lV-AI) . On the other hand, 
there is ongoing work on an Eclipse plugin that supports 
development of robot applications with the Robotics API. 
This plugin (called the RoboticsAPI plugin) provides some 
mechanisms that were useful for connecting the GSRAPID 
IDE to the environment of a robotics application, like e.g. 
the available robots in this application. We will not go into 
details about the RoboticsAPI plugin in this paper, but rather 
explain those mechanisms that were used in the realization 
of the GSRAPID IDE. 

The GSRAPID IDE basically consists of three important 
components (cf. Fig. 0]): 

1) The Tools palette, from which basic GSRAPID oper- 
ators are selected 

2) A working Canvas, where GSRAPID Diagrams are 
created 

3) A Properties View, where specific attributes and pa- 
rameters can be set for the currently selected graphical 
entity. 

The common working flow is dragging and dropping an 
element from the Tools palette onto the Canvas (to the 
right hierarchy level inside the Diagram) and then setting 
its properties in the Properties View. 

A. Technologies 

A variety of technologies was used to develop the 
GSRAPID IDE with all its components. At this point, we 
briefly present the concepts behind those technologies before 
their application in this context is described in the later 
sections. 

I) Eclipse Modeling Framework: The Eclipse Modeling 
Framework (EMF) allows to generate a complete Eclipse 
plugin based on abstract model definitions. The advantage of 
using EMF for plugin development is, that a) a lot of code 
required for managing model instances at program runtime 
can be generated and b) the generated code is guaranteed 
to work correctly, according to the model definitions. EMF 
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Fig. 4. Plugin user interface for creating commands in the graphical 
language 



also provides support for creating a properties view, which 
is frequently used for defining GSRAPID Diagrams. 

2) Graphical Modeling Framework: In order to create 
a graphical modeling environment, though, EMF is not 
sufficient. This is where the graphical modeling framework 
(GMF) comes into place. It enhances the functionality of 
EMF by using and adapting components of Eclipse's graph- 
ical editing framework (GEF). By defining three additional 
models, i.e. the graphical model, the tooling model and the 
mapping model, a stub for a completely functional graphical 
modeling plugin can be generated. 

3) Java Remote Method Invocation: The Java Remote 
Method Invocation (RMI) enables the access to objects and 
methods executed in a different process or even on a different 
physical system. This mechanism is needed for some parts of 
the communication to the RoboticsAPI plugin, as explained 
later. By design of RMI, the calls to functions hosted in 
a remote Java environment are almost identical to local 
function calls, resulting in a high degree of transparency. The 
only difference of remote calls is the necessity of additional 
exception handling, related to the dynamics of distributed 
environments [16] 

4) Java AST/DOM: Java AST/DOM is one of Eclipse's 
most basic frameworks which is responsible for a lot of 
functionalities in the IDE, e.g. refactoring. Each Java class 
definition is represented in Eclipse as an Abstract Syntax 
Tree (AST), which is similar to the Document Object Model 
(DOM), and is continuously synchronized. This way, changes 
to the code always have an abstract representation which e.g. 
also makes code outlines available [17]. 

B. Data Model 

For gathering all data required for a fully specified 
GSRAPID diagram, some concepts were introduced in ad- 
dition to the classes provided by the Robotics API. The 
concepts of LogicalStates and the implicit Eventhandler 
were already discussed in IIV-CI and IIV-D1 Additionally, a 
completely new Parameter concept had to be introduced. It 
reflects parameters of graphical entities in order to meet the 
requirements for successful code generation. 

This new Parameter object is needed for the correct 
initialization of states, sensors and actions. They usually 



depend on a set of input parameters, like e.g. start and goal 
positions of a robot movement Action. These parameters are 
specific to the respective Action and thus handled by the 
Property View of the GSRAPID IDE in a generic way. 

The values of those Parameters can be constant values 
entered by the useJE In some cases though, it is desirable 
to determine the parameter value dynamically by e.g. calling 
a method. This is supported by the dynamic method search 
capabilities of the GSRAPID IDE (cf. Sec. lV-Cl) . For all other 
cases (where neither a constant value nor a simple method 
call is sufficient), a parameter may be assigned a variable 
name. The code generator then creates setter methods for all 
those variables, which have to be called before the generated 
Command is executable. 

C. Dynamic Method Search 

When specifying that a parameter of a GSRAPID operator 
should be determined by a method call at runtime, the 
object instances available at runtime have to be known, as 
well as their methods. The Robotics API plugin maintains a 
special runtime context for each robotic application that is 
created as project in an Eclipse- Workspace. In this runtime 
context, an instance of the RoboticsAPI library is loaded 
and configured according to special configuration files of the 
respective Eclipse project. That means that in this context, 
e.g. instances of all RoboticsAPI Devices are created and 
can be accessed, as well as all class definitions inside the 
Robotics API. By using the mechanisms of Java Reflection^, 
this runtime context can be browsed and methods can be 
searched that comply to certain requirements (e.g. returning 
values of certain datatypes). 

The GSRAPID IDE employs these mechanisms and uses 
a heuristical approach to find methods that might be feasible 
for determining values of GSRAPID operator Parameters at 
runtime. The approach looks for appropriate methods in a 
certain "context" of the current GSRAPID diagram, which 
includes e.g. the Actuators and Sensors used, as well as the 
set of methods available in the Command classes. 

As the runtime context for Eclipse projects is hosted as 
a separate operating system process by the RoboticsAPI 
plugin, Java RMI is used for communicating with those 
processes. Feasible methods are suggested to the user in a 
dropdown list in the properties (cf. Fig. 2J. The GSRAPID 
IDE also supports recursive usage of this mechanism for 
determining arguments of methods using the same dynamic 
definition. 

D. Code Generation 

Once GSRAPID Diagrams have been graphically speci- 
fied, they can be translated into Java code to be usable inside 
a RoboticsAPI project. For this purpose, a code generator 
can be triggered by the user. Its main task is to interpret 
the graphical Command and the values of the respective 
operator properties. The challenge here is to correctly process 
every operator and all inter-operator dependencies (defined 

3 In case the parameters are primitive types like Integer, Boolean, etc. 
4 http://java.sun.com/developer/technicalArticles/ALT/Reflection/ 
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Fig. 5. Setting the needed input parameters for an action 



by nesting or operator connections). For this purpose, the 
instance of the EMF model corresponding to a GSRAPID 
Diagram is parsed and a Java Abstract Syntax Tree is 
generated, according to an algorithm whose flow is roughly 
depicted in Fig. [6) 
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Fig. 6. Workflow of the code generator 

Each entity evaluated by the code generator is checked 
for contained States, which are translated to Java code first. 
Depending on the type of State, its parameters have to be 
translated before translating the State itself. Additionally, for 
TransactionCommands, inner Commands are handled before 
the TransactionCommand itself. 

The translation of LogicalStates is delayed until all other 
States have been handled. This ensures that all "precon- 
dition" States have already been translated and the result 
can be used in the translation of LogicalStates. EventEffects 
are translated after all (Logical) States habe been processed. 
At this point during the process, every source and target 
object for the EventEffect connection is guaranteed to be 
initialized. The method stubs and member variable dec- 
larations are taken care of whenever needed during code 
generation. The result of the code generation is a Java class 
with static setter methods for property variables and a static 
method that instantiates the Command structure as defined 



with GSRAPID. The implementation of this method checks 
whether all generated setter methods have been called before, 
otherwise an error is thrown. 

VI. Example 

To demonstrate the usage and expressiveness of 
GSRAPID, we present in this section an example Diagram 
and the steps required to execute the code generated from 
it. The task that should be realized can be described as fol- 
lows: Two Lightweight Robots should carry some workpiece 
cooperatively. During their motion, they pass a container, 
in which they should drop the workpiece. This task clearly 
contains some real-time aspects: The motion of both robots 
must be synchronized in order to achieve a cooperative 
transport. Furthermore, dropping the workpiece by opening 
the grippers must be triggered at exactly the right time 
during movement in order to not miss the container. Both 
grippers have to be opened exactly at the same time as well, 
otherwise the workpiece might be stuck too long in one of the 
grippers and also miss the container. To further increase the 
complexity, the case that the workpiece actually got stuck 
during dropping should be handled. This can be done by 
observing the downward force measured by the robot arms. If 
the grippers have already been opened and still a significant 
downward force is measured, the workpiece is assumed to 
be stuck. In this case, movement of the robots should be 
stopped immediately. 

Fig. [7] shows a GSRAPID Diagram that realizes this task 
by combining all necessary actions in one RoboticsAPI 
Command. The TransactionCommand in the left part of the 
Diagram (move Parallel) contains two RuntimeCommands, 
each one controlling one of the robot arms (leftLWR and 
rightLWR). Both RuntimeCommands let the robots execute 
a linear motion (LIN). The parameters of these linear motions 
are defined to be variables, which have to be set before the 
code generated from the Diagram can be executed (cf. List- 
ing |2]). Assuming appropriate parameterization of those LIN 
Actions, the parallel execution of the RuntimeCommands 
will result in uniform motion of both robot arms. 

The right part of the Diagram models two RuntimeCom- 
mands inside a second TransactionCommand called open- 
Grippers. Those RuntimeCommands execute SetDigitalValue 
Actions for setting high values on specific field bus outputs. 
These signals tell the robot grippers connected to those 
field bus outputs to open. The parallel starting of both 
RuntimeCommands ensures that the grippers are opened at 
the same time. The openGrippers TransactionCommand is 
started on the occurrence of a State that is supplied by the 
LIN Action of one of the robots. This Action offers a method 
motionAtPercent (p) that supplies a State indicating that the 
motion has reached P percent of its execution time. When a 
State entity is added to the GSRAPID Diagram and is placed 
inside the LIN Action entity, the GSRAPID IDE offers this 
method as one possibility for defining the State (cf. Fig. 0. 

Handling the case of the workpiece getting stuck is par- 
ticularly interesting: To detect that the workpiece is stuck, 
the force sensors of both robot arms are observed. This is 



modelled in the Diagram by adding Sensors to both leftLWR 
and rightLWR. After that, the user has to choose which kind 
of Sensor to use. The method qe tForceXSensor ( ) of the robots' 
class lwr is offered to the user as one option (cf. Fig. 2J. 
The same mechanism is used to determine appropriate States 
(defined here by the Sensor's method isGreater (f ) ) based on 
the Sensors' measurements. The States are then combined 
with an OrState so that both measurements are considered. 
Additionally, the CompletedState of the TransactionCom- 
mand openGrippers is used so that the force measurement 
is only considered after the grippers have been opened. All 
States are finally combined by an AndState, which then 
triggers an EventEffect that is stopping the moveParallel 
TransactionCommand. 

The code generated from this Diagram consist of about 
150 lines. Due to its complexity (cf. Listing [T]), writing this 
code by hand is not an easy job. For other programmers that 
want to re-use or adapt the code, understanding it is even 
harder. On the other hand, the semantics of the Command 
can in most cases be inferred at first glance when looking 
at the GSRAPID Diagram. Listing [2] shows the usage of the 
generated code in a robotics application. As the Diagram was 
entitled "Example", a Java class Example is generated. This 
class contains static setter methods for all variables used in 
the Diagram (in this case, the start and goal poses of the 
LIN Actions) as well as a static method that instantiates the 
Command as defined in the Diagram. 



// Set parameters under-specified in the Diagram 
Example . setLeftRobot Start (Frames . LeftRobot Start ) ; 
Example . setLeftRobotGoal (Frames . Lef tRobotGoal ) ; 

Example . setRightRobotStart (Frames . RightRobot Start ) ; 
Example . setRightRobotGoal (Frames . RightRobotGoal ) ; 

// At this point Command instant iaton will succeed . 
Command exampleCommand = Example . createCommand() ; 

// Finally, Command can be executed. 
exampleCommand. execute ( ) ; 

Listing 2. Using code generated from a GSRAPID Diagram 

VII. Conclusion and Future Work 

The GSRAPID language and its IDE promises to be a very 
useful tool for specifying complex robot commands with the 
RoboticsAPI. First experiences showed that the process of 
defining Commands is really accelerated and the resulting 
diagrams are quickly understandable. However, we have to 
investigate the applicability of GSRAPID to more complex 
examples to find out how well the graphical specification 
scales with the problem complexity. 

The future plans with GSRAPID are twofold: On the one 
hand, we want to further test GSRAPID with different kinds 
of hardware and different kinds of tasks to further explore 
its usefulness as well as potential for improvements. On the 
other hand, some of the more special Robotics API concepts 
have not yet been integrated in the GSRAPID language. 
An example are so called WrappedActions that can be used 
for nesting Actions to e.g. monitor safety constraints of 
Action implementations. We want to extend GSRAPID in 
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Fig. 7. Example Diagram created with the GSRAPID IDE 



this direction. These extensions will also be interesting to 
find out the effort required for extending the language and 
the respective EMF, GMF and GEF models. Until now, our 
experience is that these technologies are powerful and well 
designed, though their complexity requires some learning 
time. 
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